“Pennsylvania State University – GeoViz Toolkit”

VAST 2011 Challenge
Mini-Challenge 2 – Computer Networking Operations at All Freight Corporation

Authors and Affiliations (Alphabetical):
Nicklaus A. Giacobe, Penn State University, College of IST, nxg13@ist.psu.edu [PRIMARY contact]
Sen Xu. Penn State University, Department of Geography, sux100@psu.edu

Faculty Advisers:
David L. Hall, Penn State University, College of IST,
dhall@ist.psu.edu
Alan MacEachren, Penn State University, Department of Geography,
MacEachren@psu.edu

Tool(s):

We used the GeoViz Toolkit to display and render the security data. The security data was tabulated and analyzed with custom written scripts using Perl to parse the logs to create simple representations of frequency of events and where they occurred on the network.  There no customization of GeoViz Toolkit.  It was used as-is to represent the data.  The effort was in the writing of the scripts to parse the log data.  Approximately 40-60 hours of work was put into the log file parsing.

To represent the data in the GeoViz Toolkit, a geography had to be fabricated.  This simple geography of several sets of 256 blocks (one for the workstations, another for the servers, and one for the Internet) was created using ArcMap, part of ArcGIS 10 (by Environmental Systems Research Institute (ESRI). 

Video:

PennState-VAST2011-MC2.swf

(requires Shockwave Player, available from http://get.adobe.com/shockwave/)

ANSWERS:


MC 2.1 Events of Interest: Using the new situation awareness display(s), what noteworthy events took place for the time period covered in the firewall, IDS and syslog logs? Which events are of concern from a security standpoint? Limit your answer to no more than five noteworthy events. For each event, at least one of the submitted screen shots must be relevant in your explanation of the event.

During the time of the logs, the following events are noteworthy:

Event 1: On April 13, 2011, during the between the hours of 11:00 AM and 1:00 PM, three workstations were responsible for high levels of alerts on the intrusion detection system.  Their IP addresses are 192.168.1.171-173.  Because we used a one-hour time slice for the analysis of the data, we were able to detect this event within an hour of its initiation.  The IDS remained quiet for the remainder of the day and through the overnight.  Selection of the low frequency events in the Single Histogram (Figure 1, bottom-right panel) triggers coordinated views on the remaining panels, de-emphasizing non-selected data points and lines.

Figure 1 - Event 1 - Note the spike in IDS activity for the 11 AM hour.  Coordinated views for the various panels help to focus attention on the important.

We are curious about which alert type has set off the IDS. So, we select the list of individual alerts for the 11 o’clock hour and send these variables to our panels.  As we check the Parallel Plot panel, we note that the vast majority of the alerts during this hour are related to 192.168.2.171, and were related to the SnortID that starts with 11:1:10000. We select this variable in the GeoMap and fill in our spatialized geography of our workstations to show that this one machine must be scanning our entire network of workstations.

Figure 2 - Checking the alert type and destinations.

Event 2: On April 14, 2011 during the hours of 9 AM and 4 PM, two additional workstations started activity that was noted on the IDS.  Computers with IP addresses 192.168.2.174 and .175 matching SnortIDS rule 123:8:1.  We detected this during the examination of the hourly timeslice of 9AM, as the increase in alerts was significant.  We had been expecting some kind of bad behavior with the workstations between IP addresses 171 and 175 because they had come up as vulnerable during the NESSUS Scan.  We represented the both the NESSUS results and the IDS results on a bivariate map that focused our attention on those nodes likely to be compromised.  These machines were scanning the rest of the network, including all of the workstation space, as well as the address ranges of the servers, even where no servers existed.

Figure 3 – Zoom-In of the Bivariate Map with NESSUS (Green) and IDS (Blue) Data.

Event 3: On April 15, 2011, between the hours of 7 AM and 9 AM, we noted that one computer set off the IDS.  This time, it was only 192.168.2.174.  The total volume of alerts on this day was significantly less than the previous days, but this may be because the dataset ended at 10AM.


MC 2.2 Timeliness: For each event submitted in MC 2.1, how early in the course of the event would your display(s) enable a CNO team member to recognize that the event was noteworthy? For each event, specify the earliest moment of recognition as a timestamp and provide a screen shot at the earliest moment of recognition. Explain how the CNO team member had enough information to determine that the event warranted attention.

We decided that it would be appropriate for this organization to analyze computer security data on an hourly basis and represented data based on that assumption.  We believe that the size of the company does not necessarily warrant a full time intrusion detection specialist.  These duties are likely to be carried out as a collateral assignment by a server and/or network administrator already on staff at AFC.  However, the visual analytics allow for the analysts to “check in” on the current status of the network from time-to-time between other duties.  The analyst always has the ability to dig into the logs to get exact times of specific events.

Figure 4, below provides a screen shot for Event 1.  Notice in the parallel coordinate plot (used here as a time series analysis of the same variable over several time slices), that the upper bound of the value increased from <15 in the previous hours to over 2000 for more than one host.  This triggered our exploration of the data.

Figure 4: Timeliness - Down to the hour.

Because of the hourly timeslices that were used for the visualizations, the analyst will likely be able to easily understand the current status of the network over the past several hours, noting any significant differences in the most recent hour.  Automated processes would need to be implemented to collect the logs from their various sources and tabulate the interesting findings. These would likely take the form of batch scripts that would output the appropriate files for the visualization to interpret.


MC 2.3 Recommendations: What are the implications of the events discovered in MC 2.1? What report should the CNO give to the CEO and/or what actions should the CNO take to improve security?

The CNO should do the following:

1)      Mitigate the problems with the workstations that were determined vulnerable which include the ones with IP address 192.168.2.171-175.

2)      Perform vulnerability scans of all of the servers in addition to the workstation scan that has been completed.

3)      Aggregate the log data from the remaining servers and the workstations.

4)      Update the network diagram maps to include the $VCENTER Server (192.168.1.10).

5)      Remove the external web server from the domain to limit risk of compromise of the webserver leading to future compromise of other servers in the network.

6)      Configure network switches and routers to disallow directed broadcast.  Also configure to drop all packets to IP addresses not in use, especially on the server subnet.

7)      Restrict the use of the domain “Administrator” account.  Instead, give individual network administrators their own accounts with domain admin rights to track usage and compliance with policy.

8)      Disable the use of IPv6 in this enterprise unless there is a business need to have it enabled.